blktap-3.55.5-9.4 - #27
Closed
AnthoineB wants to merge 39 commits into
Closed
Conversation
Signed-off-by: Samuel Verschelde <stormi-xcp@ylix.fr>
Signed-off-by: Samuel Verschelde <stormi-xcp@ylix.fr>
Patch 8450aed "Add an option to never resolve parent path when vhd-util query is called" is already include in version v3.55.5. Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
8.3 rebase xs 20250328
Signed-off-by: Gaëtan Lehmann <gaetan.lehmann@vates.tech>
Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
Drop useless autogen build-dep
Fix a bad integer conversion that interrupts valid coalesce calls on large VDIs: - Add 0002-CP-308382-fix-sign-conversion-in-coalesce.patch - Add 0003-Fix-coalesced-size-conversion-in-vhd-util-coalesce.patch Signed-off-by: Ronan Abhamon <ronan.abhamon@vates.tech>
Release 3.55.5-2.3
Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
- Revert openssl 3 dependency from XS specfile. - Drop patch 0002-CP-308382-fix-sign-conversion-in-coalesce.patch and 0003-Fix-coalesced-size-conversion-in-vhd-util-coalesce.patch, as they are now upstream. Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech> Co-authored-by: Samuel Verschelde <stormi-xcp@ylix.fr>
8.3 rebase xs 20250908
This change rebuilds on xcp-ng-8.3 with openssl-devel-3.0.9-2.0.1.2.xcpng8.3.x86_64 Origin: #13 Signed-off-by: Philippe Coval <philippe.coval@vates.tech>
spec: Rebuild on openssl-devel-3 Origin: #13
Signed-off-by: Mathieu Labourier <mathieu.labourier@vates.tech>
…util-scan-on-vhd-with-corrupt-footer Prevent segfault of vhd-util scan on VHD with corrupt footer
Signed-off-by: Philippe Coval <philippe.coval@vates.tech> Origin: https://www.xenserver.com/#blktap-3.55.5-7.xs8.src.rpm Checksums-Sha256: 0083b771cfe1275b45f7a2eb126681bb302fb7ad32455441f6005c35ce047e54 Checksums-Sha512: 0c1114ed3ac58fb9665790b6dbbe5c2205c51c2bfe0c3ac64790497e270002d0e37c20ed23e2eb44464ebff69ca9c0ef18c1c5cf16b1a9e8413dd435855ca56b
Signed-off-by: Damien Thenot <damien.thenot@vates.tech> Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Add QCOW2 support
This change aligns file path used in blktap's scriptlet to path from
latest mdadm update.
Note that the GOTO is different in both rules because files are not
100% aligned.
The issue can reproduced by executing the scriptlet explicitly:
sudo yum reinstall blktap
Installing : blktap-3.55.5-6.3.xcpng8.3.x86_64 1/1
cat: /usr/lib/udev/rules.d/65-md-incremental.rules: No such file or directory
warning: %triggerin(blktap-3.55.5-6.3.xcpng8.3.x86_64) scriptlet failed, exit status 1
Non-fatal <unknown> scriptlet failure in rpm package blktap-3.55.5-6.3.xcpng8.3.x86_64
Or alternatively:
sudo yum reinstall mdadm
Installing : mdadm-4.2-5.xcpng8.3.x86_64 1/1
cat: /usr/lib/udev/rules.d/65-md-incremental.rules: No such file or directory
warning: %triggerin(blktap-3.55.5-6.3.xcpng8.3.x86_64) scriptlet failed, exit status 1
Non-fatal <unknown> scriptlet failure in rpm package mdadm-4.2-5.xcpng8.3.x86_64
The cause is a mdadm's udev rule that was relocated and scriptlet
fixed accordingly in related change.
On latest mdadm update, packager decided to drop downstream rule file
(as known as `65-md-incremental.rules` and relies on upstream one which
has a different naming `64-md-raid-assembly.rules`.
This renaming path broke blktap, this change realign to upstream.
From the installed state (xcp-ng-8.3.0-20250606.iso)
- blktap-3.55.5-2.1.xcpng8.3 + mdadm-4.0-13.el7 ~ /e/u/r/65*
The following scenari have been tested:
- mdadm-4.0-13.el7 (old from iso) then blktap-3.55.5-6.5.xcpng8.3 ~ /e/u/r/65*
- blktap-3.55.5-6.5.xcpng8.3 then mdadm-4.2-5.xcpng8.3 (update) ~ /e/u/r/64*
- blktap-3.55.5-6.5.xcpng8.3 then mdadm-4.0-13.el7 (downgrade) ~ /e/u/r/65*
- blktap-3.55.5-6.5.xcpng8.3 then mdadm-4.2-5.xcpng8.3 (update) ~ /e/u/r/64*
The issue can be now reproduced again with downgrade of blktap (as
observed before).
- mdadm-4.2-5.xcpng8.3 then blktap-3.55.5-6.3.xcpng8.3.x86_64 ! looking 65
Side notes
It is not necessary to update mdadm because trigger will be
run update of blktap as explained at:
- https://rpm-software-management.github.io/rpm/man/rpm-scriptlets.7
- https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#ordering
Update/downgrade scriptlet can not be grouped into single one to
detect update or downgrade, because:
- 1: Relying on presence of files is not possible, because
scriptlets are evaluated before RPM "Cleanup" task and both files can
be present.
- 2: Relying on RPM query of mdadm is not possible between states.
Origin: #17
Relate-to: XCPNG-3024
Relate-to: https://src.fedoraproject.org/rpms/mdadm/c/cdf21d08ef36728f088f69a79e30aa996ccd5a67
Relate-to: xcp-ng-rpms/mdadm@c1f0333#r181097962
Relate-to: xcp-ng-rpms/mdadm#2
Relate-to: md-raid-utilities/mdadm@2452f13#diff-cebbb0bcfc268c2e841300de2a6bdeb0c4c3110ff0f2072b782ca3a2a336a9afR19
Thanks-to: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Signed-off-by: Philippe Coval <philippe.coval@vates.tech>
Fix udev rule file triggered by mdadm (with upstream rule) Relate-to: XCPNG-3024 Origin: #17
libqcow2 included in blktap package is exclusively GPLv2 sources. Reflect this state in the RPM license list. Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Release 3.55.5-6.6: libqcow2: Dual license blktap package with GPLv2
2 issues fixed: - crash of tapdisk in ready state - infinite coalesce on loaded guest Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Release 3.55.5-6.7
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
blktap-3.55.5-9.1
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Release 3.55.5-9.2: Qcow2 fixes
Signed-off-by: Mathieu Labourier <mathieu.labourier@vates.tech>
…tap-ctl Release 3.55.5-9.3
Signed-off-by: Mathieu Labourier <mathieu.labourier@vates.tech>
fixup typo introduced in Release 3.55.5-9.3
- Fix commit command with cbt enabled. Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Main information
Work Item Reference
XCPNG-3669
Context & Motivation
This change fix the broken commit command with cbt activated.
Release Target
fast track.
Release Notes and Documentation
Explain the change to users
Attention points
N/A
Documentation update needed
This not a new feature.
PR links: N/A.
Testing and regression avoidance
What tests have you performed?
What manual tests should be performed after the build, and by whom?
I perform manual tests with/without CBT to test the consistency.
I can perform manual tests after the build.
What's covered by the xcp-ng-tests test suite?
CBT tests in xcp-ng-tests are in development but they didn't catch this issue, so a new revision of the PR will handle this case.
What tests have been or will be added to CI for this change? If none, explain why.
Yes, this is a side project here:
https://project.vates.tech/vates-global/browse/XCPNG-672/
and
xcp-ng/xcp-ng-tests#541
but not yet upstream.
Xen Orchestra Impact
Does this affect existing features in Xen Orchestra, or add new features that could be useful?
Koji build (scratch, v8.3-incoming): https://koji.xcp-ng.org/taskinfo?taskID=111618